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[57] ABSTRACT 

An improved secure communication arrangement separates 
the tasks of identity verification and certificate issuing, 
which allows a disassociating of the long-term binding 
between Alice and her public/private key pair. This is 
accomplished by a registration authority issuing a password 
to Alice once it is satisfied of Alice's bona fide. Thereafter, 
whenever Alice v^ishes to communicate with Bob, she 
contacts a certification authority, identifies herself with the 
password and obtains a private key and a corresponding 
short-lived certificate. The certificate typically includes 
Alice's name and a public key in plaintext, and a signature. 
The signature is derived by hashing the plaintext portion of 
the certificate to obtain a value, and encrypting the value 
with the CA's private key. She then contacts Bob, submits 
her certificate, Bob performs the same hashing function to 
obtain a value, decrypts the signature with CA's public key 
to obtain a decrypted value, and compares the value Bob 
created with the decrypted value. If the two match. Bob is 
assured that the person submitting the certificate may be 
communicated with by using the public key included in the 
certificate. 

37 Claims, 3 Drawing Sheets 
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CERTIFICATION PROCESS 

BACKGROUND OF THE INVENTION 

This iavention relates to certifications iised in connectioo 
with secure and authorized conunuaications. ^ 

In some applications, a user who wishes to obtain goods 
or services from a provider is asked to authorize a charge 
against the user's credit card number. In such applications, 
the security concem lies most heavily on the user, who 
worries about the security of the transmitted information. In 
other applications, a user may seek to obtain proprietary 
information from the provider, and there the security con- 
cem lies most heavily on the provider. In the latter situation, 
however, the provider is also conceraed about the identity of 
the user. 

With respect to securing communication, it is well known 
that secret keys may be used to encrypt information, but that 
requires both parties to have a secret key. Consequently, a 
party that communicates with many people needs to have ^ 
many different secret keys. The effort to securely distribute 
and manage many secret keys was considered just too great, 
until public key encryption was invented. In public key 
encryption, a party, say Alice, develops a pair of keys: one 
is private (which the party keeps secret) and one is pubUc ^ 
(which the party makes available to others). Unless her 
secret key is compromised, no one but Alice can encrypt a 
message that can be decrypted with Alice's pubUc key, and 
no one but Alice can decrypt a message that was encrypted 
with Alice's public key. Thus, public key encryption elimi- 
nates the need to securely exchange secret keys and also 
eliminates the need to have and to manage many secret keys. 

Public key encryption, however, does not eliminate con- 
cerns about the identity of the party supplying the pubUc 
key. The reason: anyone can claim to be Alice. To remedy 35 
this problem, the notion of certification was created whereby 
Bob can demand a certificate which confirms that the party 
is who it claims to be. To obtain a certificate, Alice authen- 
ticates herself to a certification authority (CA) in some 
manner that satisfies the CA. For example, the CA may ^ 
require Alice to show her driver's license, an original birth 
certificate, or even more. Alice is then given (or creates) a 
public key encryption pair, and is given a certificate that is 
derived by the CAfrom information that binds the certificate 
to Alice. The information may comprise, for example, 45 
Alice's name, some information that further identifies Alice, 
and her pubUc key. When Alice wishes to contact Bob, she 
submits her certificate and Bob decrypts it with CA's public 
key. The decrypted certificate identifies Alice and Alice's 
public key, and Bob is assured that a person named Alice 5Q 
owns a private key that corresponds to the public key which 
the decrypted certificate provided. 

This certification approach still has a problem, however, 
in that while Alice was certified by the CA at one point, she 
may no longer be certified, in the sense of still being 55 
authorized to receive the information that Bob may have. To 
that end. the certification process is augmented, requiring 
Bob to check Alice's certification against a revocation list. 
This list is accessed by downloading a revocation list at 
some regular intervals from a revocation Ust storage means, 

A number of problems remain, however, with the certi- 
fication approach, and which relate to the fact that the 
certificates are long-lived and there is a private key that is 
associated with the certificate. For one, it introduces a 
burden on the mobility of users because it requires users to 65 
cany with them their private key. Of course, that represents 
a security risk. Another problem is that the longevity of a 



certificate provides an incentive to discover, or break, the 
private key that is associated with the public key found in the 
certificate. To reduce the risk to the private key, users 
typically increase the length of their keys, but that increases 
the computational burden of the applications that encrypt or 
decrypt the communicated information. A third problem 
relates to the cost of managing and administering the valid 
and revoked certificates for large scale intranet environ- 
ments. 

SUMMARY 

The certification overhead problems are greatly amelio- 
rated by separating the tasks of identity verification and 
certificate issuing, which allows a disassociating of the 
long-term binding between Alice and her public/private key 
pair. This is accomplislied by a registration authority issuing 
a password to Alice once it is satisfied of Alice's bona fide. 
Thereafter, whenever Alice wishes to communicate with 
Bob, she contacts a certification authority, identifies herself 
with the password and obtains a private key and a corre- 
sponding certificate. The certificate typically includes 
Alice's name and a public key in plaintext, and a signature. 
The signamre is derived by hashing the plaintext portion of 
the certificate to obtain a value, and encrypting the value 
with the CA's private key. She then contacts Bob, submits 
her certificate. Bob performs the same hashing function to 
obtain a value, decrypts the signature with CA's public key 
to obtain a decrypted value, and compares the value Bob 
created with the decrypted value. If the two match. Bob is 
assured that the person submitting the certificate may be 
communicated with by using the public key included in the 
certificate. 

In accordance with these principles, the certificate that is 
issued to Alice is short-lived, perhaps valid only for a few 
hours. Such short-lived certificates remove the need for a 
revocation list, and remove the incentive for an interloper to 
discover Alice's private key. 

BRIEF DESCRIPTION OF THE DRAWING 

FIG. 1 is a diagram of a prior art certification process; 

FIG. 2 is a diagram of a certification process in accor- 
dance with the principles disclosed herein; and 

RG. 3 illustrates a certificate issued by a CA on a 
particular day. 

DETAILED DESCRIPTION 

In light of the increasing ubiquity of Internet and Intranet 
transactions and the awareness that these mediums are fairly 
insecure, the information technology industry is seeking 
solutions to the security concerns of users, and the current 
thrust is to use public key cryptography-based technologies 
such as the ITU X.509 Digital Certificate, and Secured 
Socket Layer protocol. Both Netscape and Microsoft, for 
example, use this technology to support secured sessions 
between a client and a server. 

FIG, 1 presents one embodiment of a prior art certification 
process, describing a process whereby Alice obtains a cer- 
tificate for herself, and whereby Bill employs his certificate 
to communicate with an application that resides on appU- 
cation server 10. To obtain a certificate, Alice communicates 
with a certification authority (CA) 20 in a secure manner. 
The certification authority may be a designated department 
of Alice's employer, it may be a trusted commercial concern 
(e.g., the provider of lelecommuinication services). The 
secure method of communication may be the Secured 
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Socket Layer protocol, or it may be an "in person*' interac- there is more incentive for an interloper to expend the effort 

tion. During this secure communication, Alice provides CA to compromise the private key. 

20 with whatever information the CA requires and when piG. 2 presents one embodiment of an improved process 

Alice meets the CA's criteria, CA20 provides Alice with a which eliminates the need for application server 10 to 
certificate which includes a date of issue, a public key, a s contact a revocation list processor, and which finely controls 

signature, and a private key that corresponds to the public the authorization abject of certificates, 

key pair. The signature is derived by passing the other ^ ^^^^ ^^^^^ authorization aspect of certificates, 

mformation through a hashmg function jmd cncrypUng the i^chiding Alice's name in the certificate is a form of an 

resulting value with the private key of the certification authorization check, in the sense that information is pro- 
authonty. 10 ^-^^ application server 10 to definitively identify the 

The certificate is typically long-lived— on the order of party that is accessing the application server. However, there 

months — because its primary purpose is to vouch for Alice. qq crypto graphical reason to include Alice's name in the 

More specifically, its purpose is to vouch for the fact that certificate. Indeed, situations often arise where an applica- 

secure communication can be sent to Alice by encrypting tion server is not really interested in knowing who the party 

information with the public key included in the certificate, is attribute of the party (such as, "is the 

The certification is not permanent because, to maintain a party credit worthy?"). A classic example is when a person 

high level of confidence in the security of communication, ^s^s a credit cani and the merchant is merely interested in 

it is desirable to change from time to time Alice's public/ getting paid. On the other side of the ledger, however, there 

private key pair. In addition to the natural expiration of the are instances where knowing the certificate is valid is 
certificate, there needs to be a means for revoking a oertifi- ^ insuflBcient. The fact that the person named in the certificate, 

cate when, for example,Alice'sprivate key is compromised. such as Bill, can be sent information in a secured manner 

Gace such means are included, it can also be viewed as a does not necessarily dispose of the question whether appli- 

means to revoke a certificate for reasons other than a cation server 10 should in fact grant Bill access, 

compromise of the private key, sudi as when company X no ^^e prior art, the authorization issue is addressed in the 

longer wishes Afice to have the capabUity to access com- 25 ^^^^ ^ granting a certificate the CA 

pany X resources. authorizes at least some service-providing entities, such as 

Thus, the FIG. 1 airangemeat includes a revocation list application server 10, to proceed. However, there may be 

processor 30 which stores certificates that are no longer other application senders that do not wish to convey infor- 

valid. Since more and more certificates become invalid with mation or to provide a service unless Bill belongs to a 

time, the number of certificates stored by processor 30 could particular class (e.g., an employee). Typically, the CA is in 

continually increase, unless a bound is effected. Such a the best position to ascertain whether Bill should be autho- 

bound dovetails with the notion that certificates expire rized and, when that is the case, the granting of a certificate 

naturally after some long but finite life (as indicated above, by the CA is conditioned on Bill presenting evidence to the 

typically a month or more; e.g.. 1, 2, 6, 24 months). This CA that Bill belongs to the subject class. Alas, this intro- 

allows processor 30 to discard from its memory those duces another time sensitivity to the certificate granted by 

certificates that were previously revoked and are now natu- the CA because while Bill may belong to the subject class 

rally expired. when he requested a certificate, he may no longer belong to 

When Bill wishes to access an application on application the subject class when he uses the certificate. That means 

server 10 (e.g., via the Internet), he submits to server 10 a that the reliance of prior art systems on the revocation list 

certificate which he previously received from CA20. Appli- (30) is higher. 

cation 10 hashes the plaintext portion of the received cer- In contradistinction to the prior art, in the FIG. 2 arrange- 
tificate to obtain a value, and also decrypts the signature ment the authorization issue can be shared between the CA 
portion of the received certificate with CA20*s pubUc key. and the application server, as appropriate, and there is no 
If the value obtained from the hashing function corresponds reliance on a revocation list whatsoever, 
to the value obtained from the decryption process, then jn accordance with the FIG. 2 arrangement, Alice is 
application 10 concludes that the certification is vahd; that accepted into "the fold" Uirough a contact with registration 
is, that the person who is named in the certificate is the authority (RA) 40 over a secured channel. During this 
person who has a private key that corresponds to the pubUc contact Alice submits whatever proofs and information RA 
key which is included in the certificate. 40 requires to satisfy itself of AHce*s bona fide, and once RA 
It should be easily appreciated that the eflforts of creating 40 is satisfied, it provides Alice with a public key of 
certificates, maintaining a list of revoked certificates, and certification agent (CA) 50, and it issues Alice a password, 
engaging in the communication associated with confirming RA 40 then informs CA50 of Alice's password and autho- 
certificates present key management problems. The problem rization information, either over a secured channel or by 
also extends to the protection of private keys, user mobility, 55 encrypting the information with CA 50*s public key. 
and general operation and administration. Thereafter, whenever Alice needs a certificate, she con- 
It is believed that the root cause of many of the key tacts CA 50, identifies herself with the password (or a 
management problems can be traced to the long-lived nature hardware token that increases the level of security), and 
of the certificates. When a certificate is long-lived, the perhaps submits to CA 50 some other information, such as 
possibility of it becoming invalid increases with time due to 60 the purposc(s) to which Alice wishes to apply the certificate, 
unforeseeable and/or uncontrollable events, such as com- To protect Alice's password, the communication from Alice 
promise of the employee's private key, the employee leaving can be over a secured channel, or it can be encrypted with 
the company or leaving the project that requires access CA 50' s public key. Once CA 50 has the request, it can 
authorization, etc. Long-lived certificates are also more determine whether the password is valid. If so, CA 50 
likely to be compromised because they are almost certainly 65 proceeds to ascertain whether the purpose for which the 
going to be stored on the hard drive of a user's computer certificate is requested is an authorized purpose. If it is not, 
and, sometimes, access to the computer is open. Moreover, the certificate is refused. Otherwise, CA 50 obtains a public/ 
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private key pair (e.g., process 60) for Alice, and proceeds to arrangement, Alice creates a publicVprivate key pair, pro- 
construct a certificate. Illustratively, the certificate com- vides CA 50 with her public key in addition to the other 
prises an expiration time, AHcc's public key, Alice's name, required information, and CA50 responds with a certificate. 
Alice's private key, the purpose for which the certificate was No private key information is commimicated. 
requested or some other authorization code, the name of the s Stripped to the minimum, the goals of a certificate com- 
certification authority, a serial mmiber (so that the CA can municated by CA 50 to Alice are satisfied by merely 
keep track of what certificates it issued and to whom), and associating a public key with a private key that Alice has, by 
a signature. The signature is obtained, as in the prior art, by including information which indicates that the certificate is 
hashing the plaintext information in the certificate to obtain not stale or expired, and by providing a mechanism to assure 
a value and encrypting that vahie with the private key of CA the recipient of a certificate that CA50 vouches for whatever 
50. information is commimicated by the certificate to the appli- 
Significantly, as staled above, the FIG. 2 arrangement cation server. This mechanism is a "stamping" of the cer- 
does not require an application server to download or to tificatc's information with the private key of CA. The 
otherwise access or consult a revocation list Rather, the stampingcanbeefifectedby collecting the information of the 
certificate provides all of the information that an application certificate, encrypting the collected information with the 
server 10 needs to determine that a) the certificate is valid, private key of CA 50, and presenting the encrypted result as 
and b) use of the certificate is still authorized. In accordance the certificate. Alternatively, the stamping can be effected 
with the principles disclosed herein this is achieved, at least with a signature created in accordance with the above- 
in part, by having certificates that are short-lived. That is, the described prior art techniques. 

expiration time of certificates created by the FIG. 2 arrange- The stamping by means of a signature is more compact 

ment is less than one month, and typically much less than than the encryption of the entire set of information that is 

one month. In fact, the typical certificate created by the FIG. contained in the certificate, but an even more shorter trans- 

2 arrangement may be good for only one day and perhaps for mission from CA 50 to Alice is achieved by simply not 

even less than one day. For example, the expiration time of inchidiog some of the information that Alice already has. For 

the certificate may include merely a date, a date with an ^5 example, Ahce aheady knows her name, her public key, and 

implicit time (e.g., the end of a business day), or it may the purpose for which she wishes to use the certificate (as 

include a dale and an explicit time (e.g., Mar. 18, 1997- she commimicated that purpose to CA50), Alice may even 

16:00). know that the certificate she gets will be valid only for the 

In a further improvement which generically tightens currentday only (e.g., the certification will expire at the "end 

authorizations, a certificate created by the FIG. 2 arrange- 39 of business" of the day the certificate was requested). In such 

ment may include a "number of uses" limitation. The a case, CA 50 might dispense with sending the unnecessary 

number of uses limitation may be explicit, by including a information and rather send only the information that Alice 

number in the certificate, or it may be implicit. For example, does not have, such as the signature, perhaps an authoriza- 

the FIG. 2 arrangement may be set so that each certificate is tion code, and the like (e.g., the public key of application 

honored by any application server 3 times, or a certificate is 35 server 10 — ^which is really not part of the certificate), 

honored by one application server 10 times, and by another Effectively, CA50 hmits itself to sending only the certificate 

application server only once. core, allowing Alice to construct the rest of the certificate. Of 

The fields that coaespond to the expiration time and the course, whatever Alice appends to the certificate core must 

number of uses are but two of the mechanisms to control be known to CA50 or must have been communicated to CA 

access. A third mechanism for controlling access is embod- 40 50 for inclusion in the information that is "stamped." 

ied in the information regarding the purpose for which the One additional piece of information that is included in the 

certificate was requested, or the purpose for which the above-described certificate and which might not be needed 

certificate is issued (the two may be synonymous, but not is the identity of the certification authority. If that is known 

necessarily so). The fact that CA 50 grants a certificate and and understood by whatever application servers are accessed 

includes information that allows an appUcation server to 45 by Ahce, the certificate need not include that data. This, of 

decide whether to provide access effectively transfers some course, can be a variable which depends on the information 

authorization control from CA 50 to the application servers provided by Alice to CA50. For example, when Alice wants 

to which the certificates are offered. This may be advisable to communicate with a server that belongs to her employer, 

because CA 50 may not have its authorization profiles up to the certificate will not include the CA's identity. When Alice 

date, or for other reasons it is not advisable to keep all 50 wishes to communicate with, say, the U.S. Patent and 

authorization data centrally. Of course, there are some clear Trademark OfBce (PTO), the certificate will include the 

advantages to keeping at least some authorization control CA's identity. 

centrally in CA 50. First, at least some authorization infor- With a certificate at hand, Alice contacts application 

mation is more likely to be known to CA 50; second, server 10 (e.g., via the Internet) and submits her certificate 

centralization of such information is a more efi&cient way to 55 to the server. Server 10 verifies the certificate with the pubhc 

maintain control over the myriad appUcation servers that an key of CA 50 and, if appropriate (based on the information 

enterprise might have; and third, centralization reduces the contained in the certificate), concludes that communication 

risk of information being compromised. Further, when a with Alice can proceed, dcteraaines the level of service that 

request for a certificate (for a particular purpose) does not it will provide to Alice, and knows that it needs to respond 

pass muster under the authorization information available in 60 to Alice by using Alice's public key for encryption (while 

CA 30, the grant of a certificate is simply refused. Alice may use the public key of appUcation server 10), Since 

For the certificate described above, which includes pubUc key encryption is computationally more intensive 

Alice's private key, the communication of the certificate than a symmetric secret key, the first and perhaps the only 

from CA 50 to AUce must be over a secured channel. This communication that server 10 might engage in by using 

requirement, however, may be dispensed with, and Alice 65 Alice's pubUc key is a transmission of a secret key to AUce. 

may be offered an addiUonal measure of security by allow- Since only AUce has the appropriate private key that corre- 

ing Alice to generate her own key pair. In such an sponds to the pubUc key, only AUce can decrypt and thereby 
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Utilize the secret key provided by application server 10. response from Alice). No communication by this module 

Subsequent session ooomiunications between Alice and with the ''outside world" needs to lake place and that, of 

server 10 can then take place using the secret key. While the course, is a significant advantage. 

same secret key could be used in later sessions between Alice might be restricted to only some of the resources 
Alice and application server 10, there is a clear security 5 that belong to company X, and the restrictions may be based 

advantage in using a different secret key with eadi session. on Alice's status. For example, because Alice is an employee 

To summarize, the arrangements of FIG. 1 and FIG. 2 of company X she may be entitled to access information in 

contemplate using secure communications between users the company's library; by virtue of being on the team of 

such as Alice and Authorities 20 and 40, and insecure project Y, Alice may be permitted to access files in a certain 

commimications between the users and application server 10 server; and by virtue of being the administrator of the 

(and also CA50). What the FIG. 2 arrangement saves is the company's payroll computer, Alice may be permitted to 

need for a revocation list and the need for server 10 to "bring down" the computer for maintenance. Qearly, in 

communicate with a revocation list processor 30. accordance with the principles disclosed herein, Alice can 

Correspondingly, the certificate created for the FIG. 2 obtain a number of certificates, and each certificate specifies 

arrangement differs in character from the prior art certifi- the particular authorization that is granted. Alternatively, a 

cates obtained for the FIG. 1 aaangement. If the latter is single code might suffice. When application server 10 

likened to a driver's license because it is bng-lived, then the receives a certificate that includes a number of uses 

former can be likened to a subway token or to a bus ticket Umitation, it accesses a count of the number of times the 

because it is short-lived. Also, the certificate created for the certificate had been used, increments the coimt, and when 
FIG. 2 arrangement is more like an authorization to an ^ the count exceeds the maximum number for which the 

application server than a confirmation of a party's identity. certificate is good, service is refused. 

The advantages accruing from the FIG. 2 arrangement can Of course, this approach can also be used in connection 

be appreciated by sketching out a typical arrangement. In with a- resource that is owned by other than company X. For 

such an arrangement, Alice is an employee of company X example, a company such as AT&T can provide its public 

and is stationed at location xl. Company X has many other key to another entity, say U.S. PTO, and provide a certificate 

locations and many other employees. At one of its locations, to each of its intellectual property attomeys. The PTO can 

company X maintains (for security and efficiency reasons as then receive applications, amendments, etc. over the Internet 

discussed above) an overall database of its employees and with assurance that the attorney does operate on behalf of 

processing capabilities to implement the registration author- AT&T. Illustratively, a certificate that precedes an electronic 

ity. Company X would most likely have a single registration filing of a patent application with the PTO is shown in FIG. 

authority because the communication burden on the regis- 3. 

tration authority is fairly light. When Alice needs a The notion of a transfer that is conmioQ in subway tokens 

password, which is chosen to be relatively long-lived (e.g., can also be implemented in the FIG. 2 certificates. For 

significantly more than one week), she contacts the regis- example, a particular server 10 may decide to "hand off" 

tration authority in a secure manner, as discussed above. Alice to another server. It can issue its own certificate to 

Since such communication occurs relatively infrequently vouch for Alice to that other server and offer Alice's 

(only when Alice is first quafified and thereafter only when certificate so that the other server would get Alice's public 

a new password is needed), the burden on Alice and on the key. 

infrastructure of communication into RA 40 is not great. We claim: 

In contrast to the single RA 40, company X may have a 1- A method comprising the steps of: 

certification authority 50 in each of its locations. Each of the a certification authority interacting with a user to receive 

CA 50s is supplied with information from RA 40 whenever a password from the user, 

a new password is issued to an employee that a particular CA receiving a user password from said user; 

50 is charged with servicing, or when new authorizations receiving and storing a password from a third party to 

take effect. This communication is either over a secured form a stored password; 

channel or is encrypted with the public key of CA 50, and determining whether said user password is valid by com- 

it, too, is infrequent. paring said user password to said stored password; 

When Alice wishes to obtain a certificate, she contacts her when said user password is concluded to be valid by said 

local CA 50. Again, this contact must use a secure channel 50 step of determining, developing a certificate core that 

of commimication or be encrypted with the pubhc key of CA comprises information that results from encryption of 

50. When the desired certificate is for contacting an appli- first data with a private key of the certification authority 

cation server of company X, the certificate need not identify (CA-PrKey), which first data comprises a public key of 

the CA, since that is understood. the user and a short-lived expiration time of the 

Having obtained a certificate, Alice can access any 55 certificate, and 

resource of company X throughout its far flung reaches and delivering the certificate core to the user to be used at least 

can securely communicate over a relatively insecure as part of the certificate. 

medium such as Intemct. These resources, which may be a 2. The method of claim 1 where the expiration time is less 

single computer that contains information or performs than one month from the date the certificate is issued, 
computations, or whole networks of computers that, 60 3. The method of claim 1 where the expiration time is the 

perhaps, control operations for company X, belong to com- day after the day the certificate is issued, 

pany X and it is a simple matter to have them installed with 4. The method of claim 1 where the expiration time 

knowledge of the public key of company X. Each applica- explicitly includes the time of day. 

tion that is accessed by Alice on such a remote resource 5. Hie method of claim 1 further comprising the step of 
needs only to execute a module that decrypts a certificate 65 employing at least a part of the certificate core as a certificate 

and monitors a "hand shaking" protocol with Alice (such as or appending information to at least a part of the certificate 

sending Alice a secret key and receiving a confirmatory core to form a certificate. 



03/09/2004, EAST Version: 1.4.1 



5,982,898 



10 



10 



6. The method of claim 5 where a portion of the certificate 
core is not used as part of the certificate. 

7. The method of claim 5 where the appending of infor- 
mation to form a certificate is carried out by the certification 
authority. 5 

8. The method of claim 5 where the appending of infor- 
mation to form a certificate is carried out by the user. 

9. The method of claim 1 where said first data also 
includes name of a user to whom the certificate is intended 
to be delivered. 

10. The method of claim 1 where the first data also 
includes one or more from the set containing identity of the 
certification authority, name of a user to whom the certificate 
is intended to be delivered, other information about the user, 

a field that identifies the certificate to the certification 35 
authority, a service for which the certificate is valid, a 
purpose for which the certificate is valid, an authorization 
code, a server for which the certificate is intended, and a 
number of uses of the certificate in a server. 

11. The method of claim 10 where a decision whether to 20 
include in said first data the identity of the certification 
authority is based on information provided by the user in the 
step of interacting. 

12. TTie method of claim 1 where the first data further 
comprises information provided by the user, or information ^5 
provided by the certification authority, or both. 

13. The method of claim 1 where said encryption with 
CA-PrKey comprises encryption of a value which is derived 
from a hashing of the first data, and the certificate core 
further comprises second data which comprises the public 3Q 
key of the user and the short-lived expiration time of the 
certificate. 

14. The method of claim 13 where the appending of 
information to form a certificate is carried out by the 
certification authority. 35 

15. The method of claim 13 where the appending of 
information to form a certificate is carried out by the user. 

16. The method of claim 13 where the second data further 
comprises one or more from a set comprising the name of 
the user, other information about the user, service for which 
the certificate is intended, service for which the certificate is 
valid, authorization code, expiration time of the certificate, 
or a number of uses of the certificate in a server. 

17. The method of claim 16 where the information 
appended to the certificate core to form a certificate is 45 
included in the first data. 

18. The method of claim 13 where the public key of the 
user is either provided by the user or by the certification 
authority. 

19. The method of claim 13 where the second data further jq 
comprises information provided by the user, or information 
provided by the certification authority, or both. 

20. The method of claim 13 where the informatioD 
provided by the certification authority in the second data 
includes a public key that is associated with the private key 55 
of the user. 

21. The method of claim 13 where the first data is 
identical to the second data. 

22. The method of claim 1 further comprising the steps of: 
said user providing specified information to a registration 50 

authority, 

based on said specified information, said registration 
authority ascertaining whether said user deserves to 
possess said password, and 

when said step of ascertaining concludes that said iiser 65 
deserves a password, said registration authority com- 
municates said password to said certification authority. 



23. The method of claim 22 where said registration 
authority creates said password. 

24. The method of claim 22 where said password includes 
name of said user. 

25. The method of claim 22 where in said step of said 
certification authority receiving said password from said 
user, said certification authority also receives name of said 
user, and where said registration authority communicates 
said user name to said certification authority when it com- 
mimicatcs said password to said certification authority. 

26. The method of claim 1 where said first data also 
includes name of a user to whom the certificate is intended 
to be delivered. 

27. The method of claim 1 where said first data also 
includes a service for whidi the certificate is valid. 

28. The method of claim 1 where said first data also 
includes a purpose for which the certificate is valid. 

29. The method of claim 1 where said first data also 
includes a server for which the certificate is intended. 

30. The method of claim 1 where said first data also 
includes a number of uses of the certificate in a server. 

31. A method for responding to a connection request from 
a user comprising the steps of: 

a certification authority receiving a password from a third 
party; 

said user receiving a certificate from said certification 
authority in response to a user password presented to 
said certification authority by said user; 

receiving said certificate, which contains information, 
including an expiration time; 

determining the certificate's bona fide; 

refusing to continue the connection either when the cer- 
tificate is not bona fide or when the expiration time has 
passed; and 

carrying on the connection with aid from a public key 
contained in the certificate, without reference to infor- 
mation regarding revocation of certificates, when the 
expiration time of the certificate has not yet arrived. 

32. The method of claim 31 where the step of determining 
the certificate's bona fide comprises: 

processing at least some plaintext information included in 
the certificate to obtain a value; 

encrypting the value with a public key of a known 
certification authority to obtain a signature; 

comparing the obtained signature with a signature con- 
tained in the certificate; and 

accepting a first field of information contained in the 
certificate as a bona fide expiration time and a second 
field of information contained in the certificate as a 
bona fide user public key. 

33. The method of claim 32 where the first field is either 
plaintext, encrypted with a private key of the certification 
authority that corresponds to the public key of the certifi- 
cation authority, or encrypted with a user private key that 
corresponds to the user public key. 

34. The method of claim 32 where the second field is 
either plaintext or encrypted with a private key of the 
certification authority that corresponds to the public key of 
the certification authority. 

35. The method of claim 31 where the step of determining 
the certificate's bona fide comprises: 

obtaining a public key of a certification authority; 
decrypting the certificate; and 

accepting a first field of information contained in the 
certificate as a bona fide expiration time and a second 
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field of mformatioD contained in the certificate as a 
bona fide user public key. 

36. The method of claim 31 further comprising, prior to 
the step of refusing the connection, 

a step of determining from other information contained in 
the certificate, and without reference to information 
received by the processor with respect to the received 
certificate, whether the processor should respond to the 
connection request, 



12 

where the step of refusing to continue the connection is 
executed when the step of determining concludes that 
communication should be refused. 
37. The method of claim 31 v^ere the information 
contained in the certificate which is utilized in the step of 
determining is a purpose for which the certificate is to be 
employed, a service for which the certificate is employed, an 
application server identity, or number of uses. 

» « * * * 
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